Microsoft DSRE PKI
Certificate Policy/Certification Practice
Statement
For TLS CAs
(DSRE CP/CPS)
Version 2.5
Effective Date 07/23/2020
Change Control Log
|
Revision Date |
Revision Reason |
Revision Explanation |
New Rev |
Supersedes |
Revision By |
|
12/16/2013 |
New |
· Initial version documented |
1.0 |
N/A |
Microsoft IT |
|
03/21/2014 |
Update |
· Minor corrections to 7.1, 7.2 |
1.1 |
1.0 |
Microsoft IT |
|
05/08/2014 |
Update |
· Section 4.1 & 4.2 to include certificate request pre-approval workflow · Updated appropriate sections to include addition of OCSP service. OCSP service is expected to be in place on or before 30th May 2014. · Removed reference to PAIX · Minor updates in section 7.1 |
1.2 |
1.1 |
Microsoft IT |
|
01/28/2015 |
Update |
· Revise section 5.4.1 of the CP/CPS to clarify collected events |
1.3 |
1.2 |
Microsoft IT |
|
12/20/2016 |
Update |
· Added of names and profiles of new SSL/TLS CAs · Updated maximum key usage and certificate validity period for Issuing CAs · Updated to remove reference to certificate issuance for short names, internal server names, and reserved IP address |
1.4 |
1.3 |
Microsoft IT |
|
10/30/2017 |
Update |
· Added info regarding verification of CAA records |
1.5 |
1.4 |
Microsoft IT |
|
04/16/2018 |
Update |
·
Removed
references to deprecated SHA-1 CA ·
1.6
– Multiple changes to definitions that were mostly cosmetic ·
4.4.3
– Added reference to CT ·
4.6.3
– Replace “last 39 months” with “800 days” ·
5.1.1
– Removed references to physical location of servers ·
5.1.6
– Replace “Corporate HBI” with “Microsoft Highly Confidential” ·
5.2.1
– Expanded role definitions ·
5.2.4
– Removed separation of duty requirement for activation materials ·
6.3.2
– Maximum Key Usage Period for Certificate Signing changed to 8 years ·
6.3.2
& 7.1 – Replaced end-entity certificate maximum validity to be 800 days
instead of 2 years (or 24 months) ·
7.1
– Clarified that the Signature Algorithm is SHA256RSA for multiple templates ·
7.1.2.9
– Added reference to CT and pre-certificates ·
Replaced
multiple instances of “SSL” with “TLS” ·
Replaced
“Microsoft IT” with DSRE throughout entire document, including title. ·
Made
some cosmetic changes throughout document |
2.0 |
1.5 |
DSRE PKI Team |
|
01/07/2019 |
Update |
·
1.1
and 1.3.1 and 6.1.5 removed Microsoft IT SSL SHA2 CA ·
3.2.3.2
Removed "any other method of confirmation" ·
4.2.2
updated Approver for End-entity Certificate column to be more explicit on
roles for approval ·
5.2.1
Broke out roles by Trusted and Authorized ·
6.7
removed physical location as all systems use same physical security now ·
7.1
removed profile for SSL SHA-2 Issuing CA Certificate Profile and references
to sanitized CDP and AIA locations in End Entity Certificate Profile ·
9.4.1
update hyperlink to Microsoft Privacy statement |
2.1 |
2.0 |
DSRE PKI Team |
|
3/15/2019 |
Update |
·
3.2.3.2
removed relying on a domain authorization document |
2.2 |
2.1 |
DSRE PKI Team |
|
05/22/2019 |
Update |
·
4.9.7
& 7.2 Updated CRL validity to not exceed 10 days |
2.3 |
2.2 |
DSRE PKI Team |
|
03/31/2020 |
Update |
·
1
Added text that this CP relies on DigiCert CP and adheres to Mozilla Root
Policy ·
1.5.2
Replaced contact email ·
3.2.3.2
Added domain validation process ·
4.9.1
Updated revocation reasons and timeline based on BR 4.9.1.1 ·
5.7.1
Added Bugzilla details for incidents ·
6.1.5
Updated end-entity certificate requirement language based on Mozilla requirement ·
7.1
Added serial number size requirements ·
8.4
Added clarification to audit period language and Mozilla requirements ·
9.11
Added notification details in case of merger or ownership change. |
2.4 |
2.3 |
DSRE PKI Team |
|
07/23/2020 |
Update |
·
1
Specifically referenced the DigiCert CP OID ·
1.1
Added new CA names and updated CA Type names ·
1.3.1
Added new CA names ·
3.2.3.2
Deleted text that had strikethrough ·
6.1.5
Added new CA names ·
7.1
Added new DV and OV templates for legacy and new CAs. Added new CA profiles. Corrected
some older template language. |
2.5 |
2.4 |
DSRE PKI Team |
Table of Contents
1.2
Document Name and Identification
2.
Publication and Repository Responsibilities
2.2
Publication of Certification Information
2.3
Time or Frequency of Publication
2.4
Access Controls on Repositories
3.
Identification and Authentication
3.2 Initial
Identity Validation
3.3 Identification
and Authentication for Re-Key Requests
4.
Certificate Life-Cycle Operational Requirements
4.2
Certificate Application Processing
4.5
Key Pair and Certificate Usage.
4.9 Certificate
Revocation and Suspension
4.10
Certificate Status Services
5.
Facility, Management, and Operational Controls
5.7
Compromise and Disaster Recovery
6.
Technical Security Controls
6.1 Key
Pair Generation and Installation
6.2
Private Key Protection and Cryptographic Module Engineering Controls
6.3
Other Aspects of Key Pair Management
6.5
Computer Security Controls
6.6
Life-Cycle Technical Controls.
7.
Certificate, CRL, and OCSP Profiles
8.
Compliance Audit and Other Assessments
8.1
Frequency and Circumstances of Assessment
8.2
Identity/Qualifications of Assessor
8.3
Assessor's Relationship to Assessed Entity
8.4
Topics Covered by Assessment
8.5
Actions Taken as a Result of Deficiency
9.
Other Business and Legal Matters
9.3
Confidentiality of Business Information
9.4
Privacy of Personal Information
9.5
Intellectual Property rights
9.6
Representations and Warranties.
9.11
Individual Notices and Communications with Participants
9.13
Dispute Resolution Provisions.
9.15
Compliance with Applicable Law..
This
Certificate Policy/Certification Practice Statement (CP/CPS) governs the
operations of Microsoft Digital Security & Risk Engineering (DSRE) Public
Key Infrastructure (PKI) Transport Layer Security (TLS) Certificate Authority (CA)
services and sets forth the business, legal, and technical practices for
approving, issuing, managing, using, and revoking digital Certificates within
the DSRE TLS CA hierarchy. The effective date for implementation of the
practices disclosed in this document is the date of publication of the Certificate
Policy and Certification Practice Statement (CP/CPS) and will apply to all
future CA related activities performed by DSRE PKI.
This CP/CPS relies upon the following DigiCert
CP:
2.16.840.1.114412.0.1.4
Note: Please refer to earlier versions of the
DigiCert CP and CPS for CA Policy Definitions valid from the time
period that those CAs were issued. DigiCert policy version history can
be found here: https://www.digicert.com/legal-repository/.
This CP/CPS conforms to the Internet Engineering
Task Force (IETF) RFC 3647 for Certificate Policy and Certification Practice
Statement construction. CAs within the DSRE PKI hierarchy conform to the
current version of the CA/Browser Forum (CABF) requirements including:
Baseline
Requirements for the Issuance and Management of Publicly-Trusted
Certificates, published at www.cabforum.org. In the event of any inconsistency
between this document and those Requirements, those Requirements take
precedence over this document.
This
CP/CPS adheres to Mozilla Root Store Policy Requirements:
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/
In
the event of any inconsistency between this document, the CABF Requirements,
and those Requirements, those Mozilla Root Store Policy Requirements take
precedence.
Microsoft
Corporation DSRE PKI has been established to provide TLS digital certificate
services to support operations of various Microsoft functions and business
units. DSRE PKI functions as the Certification Authority, Registration
Authority (RA), and manages TLS Certificates for Microsoft. The TLS
Certificates provide consumers with assurance regarding the authenticity and
integrity of Microsoft owned domains and servers.
The
following CAs, that are used to issue public key TLS Certificates, are within
the scope of this CP/CPS referred to here after as “DSRE TLS CAs.” Note that
legacy CAs continue to retain the legacy “Microsoft IT” name.
|
CA Type |
CA Name |
Description of
Function |
|
Microsoft
IT TLS SHA2 Issuing CA |
Microsoft
IT TLS CA 1 |
Issues
SHA2 TLS web server/client Certificates to authenticated individuals |
|
Microsoft
IT TLS SHA2 Issuing CA |
Microsoft
IT TLS CA 2 |
Issues
SHA2 TLS web server/client Certificates to authenticated individuals |
|
Microsoft
IT TLS SHA2 Issuing CA |
Microsoft
IT TLS CA 4 |
Issues
SHA2 TLS web server/client Certificates to authenticated individuals |
|
Microsoft
IT TLS SHA2 Issuing CA |
Microsoft
IT TLS CA 5 |
Issues
SHA2 TLS web server/client Certificates to authenticated individuals |
|
Microsoft
RSA TLS Issuing CA |
Microsoft
RSA TLS CA 01 |
Issues
SHA2 TLS web server/client Certificates to authenticated individuals |
|
Microsoft
RSA TLS Issuing CA |
Microsoft
RSA TLS CA 02 |
Issues
SHA2 TLS web server/client Certificates to authenticated individuals |
This
document is formally referred to as the “DSRE PKI Certificate
Policy/Certification Practice Statement for TLS CAs” (DSRE PKI CP/CPS). DSRE TLS
CAs issue Certificates in accordance with the policy and practice requirements
of this document. The “Certificate Policies” field for each end-entity (leaf) certificate
must reference the OID for the CP/CPS under which it was issued. Certificates
issued by DSRE TLS CAs must include the following Object Identifier (OID) in
the “Certificates Policies” field 1.3.6.1.4.1.311.42.1.
The following CAs are
supported by this CP/CPS:
· Microsoft IT TLS SHA2 CA 1
Microsoft IT TLS SHA2 CA 1 is part of the DSRE PKI TLS CA
hierarchy and issues SHA2 end-entity certificates. This CA has been issued a
certificate from the Baltimore CyberTrust Root CA.
· Microsoft IT TLS SHA2 CA 2
Microsoft IT TLS SHA2 CA 2 is part of the DSRE PKI TLS CA
hierarchy and issues SHA2 end-entity certificates. This CA has been issued a
certificate from the Baltimore CyberTrust Root CA.
· Microsoft IT TLS SHA2 CA 4
Microsoft IT TLS SHA2 CA 4 is part of the DSRE PKI TLS CA
hierarchy and issues SHA2 end-entity certificates. This CA has been issued a
certificate from the Baltimore CyberTrust Root CA.
· Microsoft IT TLS SHA2 CA 5
Microsoft IT TLS SHA2 CA 5 is part of the DSRE
TLS CA hierarchy and issues SHA2 end-entity certificates. This CA has been
issued a certificate from the Baltimore CyberTrust
Root CA.
· Microsoft RSA TLS CA 01
Microsoft RSA TLS CA 01 is part of the DSRE
TLS CA hierarchy and issues SHA2 end-entity certificates. This CA has been
issued a certificate from the Baltimore CyberTrust
Root CA.
· Microsoft RSA TLS CA 02
Microsoft RSA TLS CA 02 is part of the DSRE
TLS CA hierarchy and issues SHA2 end-entity certificates. This CA has been
issued a certificate from the Baltimore CyberTrust
Root CA.
DSRE TLS
CAs issue end-entity TLS Certificates for Microsoft owned domains. In limited
circumstances, DSRE TLS CAs also issue end-entity TLS Certificates for domains
owned by partners for purposes of conducting business with Microsoft. DSRE PKI TLS
CAs are operated by the DSRE PKI team.
Registration Authorities (RAs) perform identification and
authentication of subscribers for certificate issuance and revocation requests,
and pass along such requests to the Certification Authorities. RA activities are
operated by the DSRE PKI team for all Certificates issued under the DSRE TLS CA
hierarchy.
Subscribers
within the DSRE TLS PKI CA hierarchy include Microsoft employees (full-time,
part-time and contingent staff) and may be issued Certificates for assignment
to devices or applications, provided that responsibility and accountability is
attributable to the organization.
A
Relying Party is the entity who relies on the validity and binding of the
Subscriber with the public key associated with the Certificate. Relying Parties
typically include entities that may rely upon a Subscriber Certificate for
purposes of a) authenticating identity or b) encrypting communications.
DSRE PKI Policy Management Authority (PMA)
The DSRE
PKI Policy Management Authority (PMA) consists of one or more representatives
from each of the following teams Microsoft Corporate, External, and Legal
Affairs (CELA); Customer Security and Trust (CST) formerly known as Trustworthy
Computing (TwC); and DSRE PKI.
Certificates
issued within the DSRE TLS CA hierarchy can be used for server authentication,
client authentication, and SSL/TLS Secure Sessions. Certificates issued to
Microsoft’s external partners shall only be used for conducting business with
Microsoft.
|
Certificate
Type |
Assurance Level |
Description and Assurance Level |
|
MSIT
PKI TLS Certificate |
High
Assurance |
CAs
operating under this policy are hosted and managed by DSRE PKI using FIPS 140-2 Level 3 validated hardware security
modules (HSMs), and employ pre-defined and approved fulfillment practices
which include identification and authentication of the subscriber and
verification of the subject information included in the end-entity
certificate prior to issuance. |
Certificates
must only be used to the extent consistent with applicable law and for the
purposes specified in §1.4.1. CA Certificates must not be used for any
functions except CA functions. In addition, end-user Subscriber Certificates
shall not be used as CA Certificates.
This CP/CPS is administered by the DSRE PKI PMA at Microsoft
Corporation.
Contact information is listed below:
DSRE PKI Practices Administrator
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052-6399
centralpki@microsoft.com
The DSRE PKI PMA, as defined in §1.3.5, determines suitability of
CPS for the policy.
The CP/CPS will be maintained in a repository available to the
public. The CP/CPS shall be reviewed by the DSRE PKI PMA at least annually or
in the event of a major change. The DSRE CP/CPS is prepared and reviewed by
Microsoft DSRE PKI team and submitted to the DSRE PKI PMA for their approval.
Conditions for approval by the PMA include:
· Certificate – An electronic document that uses a digital signature to
bind a public key and an identity.
· Certification Authority (CA) – An organization that is responsible for
the creation, issuance, revocation, and management of Certificates. The term
applies equally to both Roots CAs and Subordinate CAs.
· Certification
Authority Authorization (CAA) – From RFC 6844 (http:tools.ietf.org/html/rfc6844): “The
Certification Authority Authorization (CAA) DNS Resource Record allows a DNS
domain name holder to specify the Certification Authorities (CAs) authorized to
issue certificates for that domain. Publication of CAA Resource Records allows
a public Certification Authority to implement additional controls to reduce the
risk of unintended certificate mis-issue.”
· Certificate Policy/Certificate Practice
Statement – A set of rules governing
the operation, applicability, and use of a named set of Certificates for a
defined set of users.
· Certificate Revocation List (CRL) – A regularly updated time-stamped list of
revoked Certificates that is created and digitally signed by the CA that issued
the Certificates.
· Certificate Signing Request (CSR) – A message sent to the certification authority
containing the information required to issue a digital Certificate.
· Certificate Transparency (CT) – Provides an auditing and monitoring
system that lets any domain owner or Certification Authority (CA) determine
whether their certificates have been mistakenly issued or maliciously used.
· Compromise - A loss, theft, disclosure, modification, unauthorized use,
or other breach of security related to a Private Key.
· Distinguished Name (DN) – The Distinguished Name (DN) is used on
Certificates and in the Repository to uniquely represent a Subject identified
in a Certificate.
· Hardware Security Module (HSM) –A specialized hardware system designed to
securely store cryptographic keys and perform cryptographic operations.
· Object Identifier (OID) – A unique alphanumeric/numeric identifier
registered under the International Standards Organization's applicable standard
for a specific object or object class.
· Online Certificate Status Protocol (OCSP) – An online Certificate-checking protocol
that enables an OCSP Responder to determine the status of an identified
Certificate by contacting the Repository.
· Policy Management Authority (PMA) – The DSRE PKI Policy Management Authority
which creates and maintains the policies related to the DSRE Public Key
Infrastructure.
· Private Key – The key of a Key Pair that is kept secret by the holder of
the Key Pair, and that is used to create Digital Signatures and/or to decrypt
electronic records or files that were encrypted with the corresponding Public
Key.
· Public Key – The key of a Key Pair that is intended to be publicly
shared with recipients of digitally signed electronic records and that is used
by such recipients to verify Digital Signatures created with the corresponding
Private Key and/or to encrypt electronic records so that they can be decrypted
only with the corresponding Private Key.
· Public Key Infrastructure (PKI) – A set of hardware, software, people,
procedures, rules, policies, and obligations used to facilitate the trustworthy
creation, issuance, management, and use of Certificates and keys based on
Public Key Cryptography.
· Registration Authority (RA) – Any Legal entity that is responsible for
identification and authentication of subjects of Certificates, but is not a CA,
and hence does not sign or issue Certificates. An RA may assist in the
certificate application process or revocation process or both. When “RA” is
used as an adjective to describe a role or function, it does not necessarily
imply a separate body, but can be part of the CA.
· Relying Party – Any natural person or Legal entity that relies
on a Valid Certificate. An Application Software Supplier is not considered
a Relying Party when software distributed by such Supplier
merely displays information relating to a Certificate.
· Repository – An online database containing publicly-disclosed PKI
governance documents (such as Certificate Policies/Certification Practice
Statements) and Certificate status information in the form of a CRL.
· Transport Layer Security(TLS)/Secure
Socket layer (SSL) – Security
protocol that is widely used in the internet for authentication and
establishing secure sessions.
· Subscriber – A natural person or Legal Entity to whom a
Certificate is issued and who is legally bound by a Subscriber Agreement.
· Subscriber Agreement – An agreement between the CA and the
Applicant/Subscriber that specifies the rights and responsibilities of the
parties.
The
Microsoft DSRE PKI team maintains a public repository located at http://www.microsoft.com/pki/mscorp/cps
DSRE PKI shall publish this CP/CPS, DSRE TLS CA Certificates, and
current CRLs for the DSRE TLS CAs, and other information relevant to
Subscribers and Relying Parties in the online PKI repository http://www.microsoft.com/pki/mscorp/cps. The DSRE PKI team also maintains a database of
issued TLS Certificates to which access is restricted to authorized Microsoft
personnel.
In the event of a change to this CP/CPS, an updated version of
this document will be published in accordance with §1.5.4 after approval from
the PMA. The new version of this CP/CPS will become effective immediately for
all participants listed in §1.3. CRLs are published in accordance with §4.9.7.
Information
published in the Microsoft Corporation Internet website repository is publicly
accessible information. Physical and logical access controls are used to
restrict write access to authorized Microsoft personnel.
Certificates
are issued in accordance with the X.509 standard. All Certificates require a
Distinguished Name in the subject field or a set of Subject Alternative Name
values in the Subject Alternative Name extension. In the case where subject
identity information is contained solely in the Subject Alternative Name
extension, the Subject field of the Certificate may be empty.
The Issuer and Subject fields for Certificates issued by DSRE PKI
are populated in accordance with §7.1.
The Distinguished Names assigned to the DSRE TLS CAs and
Subscribers shall be meaningful and shall have a reasonable association with DSRE
TLS CAs and organization.
No
stipulation.
No
stipulation.
No stipulation.
No
stipulation.
The
Subscriber’s Certificate request shall contain the public key to be certified
and be digitally signed with the corresponding private key.
DSRE PKI
authenticates Organization information in each request in compliance with
CA/Browser Forum’s TLS Baseline Requirements.
DSRE PKI
determines that the organization information submitted in the request is
accurate by validating against a qualified independent information source, or
alternatively, an approval from the legal team to confirm the existence of the
organization.
All Microsoft employees may submit requests for
Certificates to be issued by DSRE TLS CAs. Subscriber identity is authenticated
by the RA application using the Windows Authentication against the enterprise
directory. For each domain
name included in the Certificate application, DSRE PKI authenticates the
Subscriber’s right to request a Certificate for the domain based on an approval
from the requester’s manager who shall be a fulltime employee of Microsoft.
DSRE PKI
issues Certificates only for the domains that are owned by Microsoft, and in
limited circumstances, to domains that are owned by partners for conducting
business with Microsoft. DSRE PKI verifies authorization for domain name
through one of the applicable procedures in compliance with CA/Browser Forum’s TLS
Baseline Requirements:
· Verification against a qualified independent
information source;
· Communicating with
Microsoft’s domain administration team
Microsoft
owned domains are validated against the database for the registrar used by
Microsoft. Any other domains are validated against public whois
information. If domain contact is not available from the Microsoft registrar or
public whois data, the contact will be created by
using 'admin', 'administrator', 'webmaster', 'hostmaster',
or 'postmaster' as the local part, followed by the at-sign ("@"),
followed by an Authorization Domain Name. An email with a random value is sent
to the domain contact from the previous steps. The domain contact must provide
the random value to prove ownership.
Not
Applicable.
All
Microsoft employees are authorized to submit requests for Certificates to be issued
by DSRE TLS CAs. Requests for Certificates shall be approved by the Certificate
applicant’s direct Manager or a Manager up to two levels higher in the
organization chain.
No
stipulation.
Requests for routine re-key of Subscriber
Certificates are treated as new certificate requests and DSRE PKI performs the
same identification and authentication checks as described in §3.2. Routine re-key of the DSRE
TLS issuing CA certificates shall be performed in accordance with DSRE PKI Key
Generation process and the third-party Root CA re-key procedures.
Requests for re-key of
Subscriber Certificates after revocation are treated as new certificate
requests and DSRE PKI performs the same identification and authentication
checks as described in §3.2.3.4 Identification and Authentication for
Revocation Request
A
Subscriber Certificate revocation request is valid if it complies with one of
the following requirements:
· The request is raised through the RA application
or
· If a revocation request is not raised through
the RA application, the DSRE PKI shall perform sufficient procedures to
manually authenticate the Subscriber’s request.
Revocation
service requests for DSRE TLS CA Certificates are required to be approved by
the DSRE PKI PMA prior to being processed.
Prior
to an end-entity certificate being issued, the Subscriber submits a Certificate
application through the RA application.
Certificate requests for OCSP responder
certificates are submitted to the CA application by authorized DSRE PKI
personnel.
All Microsoft employees
can submit Certificate applications for subscriber end-entity certificates.
Authorized
applicants shall begin the enrollment process by submitting a Certificate
application through the enrollment website. Certificate fields are to be
populated in accordance with DSRE Certificate profile requirements. The
requestor and subject information in the Certificate are validated as per §3.2.
Upon completion of the validation steps, the Certificate application shall be
approved by a Microsoft full time employee who is a manager in the management
chain of the applicant requesting the Certificate. The applicant has the option
of selecting an approver in direct line of management above the applicant (up
to three levels) within the same organization. Managers or authorized
individuals representing a user group within Microsoft may provide pre-approval
for certificate requests made by members of that group, via individual user or
service accounts, for a pre-determined list of Microsoft-owned domains.
Approvals are documented and are required to be re-authorized on a periodic
basis.
Subscribers
are required to sign a Subscriber agreement regarding the usage of an issued TLS
Certificate in accordance with CP/CPS.
Certificates are
generated, issued and
distributed only after the required identification and authentication steps are
completed in accordance with §3 and DSRE’s PKI Operations Guide.
See
§3.
The
following approvals shall be obtained prior to Certificate issuance and are
dependent on the Certificate type and assurance level.
|
|
CERTIFICATE LEVELS WITHIN THE DSRE PKI |
|
|
CERTIFICATE ASSURANCE |
Approver for Issuing CA Certificate |
Approver for End-entity |
|
High Assurance |
PKI
Policy Management Authority (PMA) |
· Applicant’s Manager in the management chain or authorized
individuals representing a user group · DSRE PKI
Team (where applicable for banned domain exception processing) · Microsoft Domains Administration Team (where applicable
for domain exception processing) |
Certificate
applications, where possible, shall be processed within three (3) business
days.
CAA record verification is done in conformance with Baseline
Requirements for Issuance and Management of Publicly Trusted certificates set
forth by the CA/Browser Forum. CAA checking is not performed for FQDNs where
Microsoft, or one of its Affiliates, is the DNS operator. For all other FQDNs,
CAA records are checked and if a CAA record exists that does not list ssladmin.microsoft.com as
an authorized CA, the certificate is not issued.
Certificates
are generated, issued and distributed only after required approvals have been
obtained and the required identification and authentication steps have been
successfully completed in accordance with §3.2.2, §3.2.3, §3.3, and
§3.4. Once the registration process is completed and the requestor is
approved for a certificate, the CA will take reasonable steps to:
- Authenticate the source of the request before
issuing the certificate
-
Verify that certificate fields and extensions are populated in accordance with
the approved certificate template
-
Generate a certificate containing appropriate Public keys, OIDs, dates, etc.
-
Notify the RA application that the certificate is available for distribution
Subscribers
are notified of Certificate creation upon issuance via email and are provided
access to their Certificates for download and installation.
By accepting a Certificate, the Subscriber:
· Agrees to be bound by the continuing
responsibilities, obligations and duties imposed by the DSRE PKI CP/CPS;
· Agrees to be bound by the DSRE PKI Subscriber Agreement;
· Represents and warrants that to its knowledge no
unauthorized person has had access to the private key associated with the
Certificate; and
· Represents and warrants that the Certificate
information it has supplied during the registration process is truthful and
accurate.
Upon
receipt of a Certificate, the Subscriber is responsible for verifying that the
information contained within the Certificate is accurate and complete and that
the Certificate is not damaged or otherwise corrupted. In the event the
Certificate is inaccurate, damaged or corrupted, the
Subscriber should contact the CA to have the Certificate replaced as determined
by the CA.
A
Subscriber’s receipt of a Certificate and subsequent use of the key pair and
Certificate constitute Certificate acceptance.
DSRE TLS CA Certificates will be published
within the DSRE repository (see §2.1). Subscriber Certificates can be
downloaded by Subscribers from the RA application.
Microsoft
may notify the public of the issuance of a certificate by adding it to one or
more publicly accessible Certificate Transparency (CT) Logs.
Use of a TLS Certificate is permitted once the Subscriber
has agreed to the Subscriber Agreement. The Certificate shall be used in
accordance with the Subscriber Agreement and the terms of this CP/CPS.
Subscribers
and CAs use their private keys for the purposes as constrained by the
extensions (such as key usage, certificate policies, etc.) in the Certificates
issued to them.
Subscribers
are required to protect their private keys from unauthorized use and
discontinue use of the private key following expiration or revocation of the
Certificate.
Relying
parties shall use public key Certificates and associated public keys for the
purposes as constrained by the extensions (such as key usage, certificate
policies, etc.) in the Certificates. A Relying Party is responsible for
verifying the validity of the Certificate prior to relying on any Certificate.
DSRE TLS
CAs support certificate renewals as specified in the following sections.
Renewal requests may be submitted for
certificates issued by DSRE TLS CAs as
long as the existing certificate is valid (i.e., not
expired or revoked).
Renewal requests shall be submitted by the subscriber, certificate
owner (can be the same person as the subscriber), or a delegate. Such requests
must be signed using the existing certificate (key based renewal).
DSRE TLS CAs performs all identification, authorization, and
validation checks specified in §3.2 during renewal. Authorization checks as
specified in §3.2.5 may not be performed if DSRE TLS CAs obtained such
authorization for the existing certificate within the last 800 days.
Subscriber are notified
of new certificate issuance through emails.
No Stipulation.
Any
certificate re-key request shall be treated as initial certificate issuance.
Refer to §4.3.
No Stipulation.
No Stipulation.
No Stipulation.
No Stipulation.
No Stipulation.
No Stipulation.
Any
certificate modification request shall be treated as initial certificate
issuance. Refer to §4.3
No Stipulation.
No Stipulation.
No Stipulation.
No Stipulation.
No Stipulation.
No Stipulation.
DSRE PKI supports Certificate revocation for all DSRE TLS CAs. DSRE
PKI does not support Certificate suspension for DSRE TLS CAs.
DSRE PKI,
through the RA application, maintains a continuous 24x7 ability to accept and
respond to revocation requests. Inquires related to Certificate revocations are
sent to an e-mail address monitored by the DSRE PKI Team.
DSRE TLS
CAs publicly disclose to Subscribers, Relying Parties, Application Software
Suppliers, and other Third Parties, instructions for reporting suspected Private
Key Compromise, Certificate misuse, or other types of fraud, compromise,
misuse, inappropriate conduct, or any other matter related to Certificates.
When
a revocation request or Certificate problem is reported through email, DSRE PKI
will begin investigation within 24 hours of receipt of such a request to decide
whether revocation or other appropriate action is warranted.
DSRE PKI
maintains a continuous 24x7 ability to accept and respond internally to a
high-priority certificate problem report and where appropriate, forward such a
complaint to law enforcement authorities and/or revoke a Certificate that is
the subject of such a complaint.
Revocation
may take place at the discretion of the DSRE PKI in the event
that the security or integrity of the Certificate (or information
contained within it) is compromised. When confirmed, DSRE PKI shall revoke an TLS
Certificate within 24 hours if one or more of the following circumstances
occur:
· The Subscriber requests in writing that DSRE PKI
revoke the Certificate;
· The Subscriber notifies DSRE PKI that the
original Certificate request was not authorized and does not retroactively
grant authorization;
· DSRE PKI obtains evidence that the Subscriber’s
Private Key (corresponding to the Public Key in the Certificate) has suffered a
Key Compromise, or that the Certificate has otherwise been misused;
· DSRE PKI obtains evidence that the validation of
domain authorization or control for any Fully Qualified Domain Name or IP
address in the Certificate should not be relied upon.
When
confirmed, DSRE PKI shall revoke an TLS Certificate within 5 days if one or
more of the following circumstances occur:
· DSRE PKI is made aware that a Subscriber has
violated one or more of its material obligations under the Subscriber Agreement;
· DSRE PKI is made aware that a Wildcard
Certificate has been used to authenticate a fraudulently misleading subordinate
Fully-Qualified Domain Name;
· DSRE PKI is made aware of a material change in
the information contained in the Certificate;
· DSRE PKI is made aware that the Certificate was
not issued in accordance with this CP/CPS or CA/Browser Forum’s TLS Baseline Requirements;
· DSRE PKI determines that any of the information
appearing in the Certificate is inaccurate or misleading;
· DSRE PKI ceases operations for any reason and
has not planned to continue to provide revocation support for the Certificate;
· DSRE PKI’s right to issue Certificates is
revoked or terminated, unless DSRE PKI has planned to continue maintaining the
CRL/OCSP Repository;
· Revocation is required as per this CP/CPS;
· As required by the law; or
· The technical content or format of the
Certificate presents an unacceptable risk to Application Software Suppliers or
Relying Parties.
DSRE PKI
may invoke its incident handling procedures if it considers a compromised
subscriber certificate to have significant impact to the security of Microsoft
platform customers. In such a situation, DSRE PKI may revoke the certificate
using “disallowed CTLs” method in addition to publishing CRLs.
Certificate revocation can be requested by Subscribers,
Subscriber’s Manager, or delegates (See §4.9.3) as identified in the RA
application. Revocation can also be initiated at the discretion of DSRE PKI.
Each
Certificate has at least one owner (can be the same as the Subscriber) and two
delegates, one of which is the Subscriber’s Manager as assigned in the RA
application. Revocations requests are submitted by either the Certificate owner
or a delegate through the RA application. A notification mail is sent to the
Certificate owner and custodians informing them of the revocation request. The
revocation request has to be approved by the owner of
one of the delegates and the approver cannot be the same persons as the
requestor.
Fulfillment
of the revocation is done by marking a Certificate as revoked in the CA system
and then submitting a CRL service request to the system to generate the
appropriate CRLs. Depending upon how the revocation request was received, the
fulfillment is performed either automatically by the RA application (for
requests received in the RA application) or by the DSRE PKI Team (for requests
received through emails).
The
CRLs are then posted and distributed by the DSRE PKI as per § 4.9.7.
No stipulations.
Revocation
requests submitted through the RA application are revoked immediately following
necessary approvals. Revocation requests submitted through emails are
investigated and fulfilled as per §4.9 and §4.9.1.
A
Relying Party shall use the validation service (i.e. CRL or OCSP) prior to
relying on any Certificate. Reliance without using the validation service will
be considered an unreasonable reliance on the Certificate in question.
CRLs
for Subscriber TLS Certificates shall be issued at least once every 4 days and
shall be valid not more than 10 days. CRLs may be issued more frequently at the
discretion of DSRE PKI.
DSRE PKI will publish CRLs no later than the
time specified in the “nextUpdate” field of the
previously published CRL.
Status information for certificates issued by the DSRE CAs is
available using OCSP. Responses can be submitted through http://ocsp.msocsp.com. Information provided via OCSP is updated at
least every four days in conformance with Baseline Requirements for Issuance
and Management of Publicly Trusted certificates set forth by the CA/Browser
Forum. OCSP responses from this service are configured with a maximum
expiration time of 24hrs.
Not applicable.
In an event or suspected or actual CA key
compromise, DSRE PKI management, in conjunction with the PKI PMA, will assess
the situation and determine the appropriate course of action to confirm and
address the compromise. If deemed necessary by Microsoft, Microsoft shall use
commercially reasonable efforts to notify potential Relying Parties if DSRE PKI
discovers, or has reason to believe, that there has been a compromise of a TLS
CA private key.
Not
applicable.
Not
applicable.
Not
applicable.
Not
applicable.
See §4.9.8 and §4.9.7.
No stipulation.
No stipulation.
No stipulation.
The escrow of CA and Subscriber TLS private keys, for purposes of
access by law enforcement or any other reason, is not supported by DSRE PKI.
Not
applicable.
Not
applicable.
The
locations of the production and disaster recovery DSRE PKI facilities, housing
CA equipment and cryptographic materials, are consistent with facilities used
to house high value, sensitive information.
All
CA operations are conducted within physically protected environments that
deter, prevent, and detect unauthorized use of, access to, or disclosure of
sensitive information and systems.
DSRE TLS CA systems are hosted and managed within secure facilities,
that are constructed to have multiple tiers of physical security and employ a
variety of controls to prevent and detect the unauthorized use of and access to
sensitive DSRE assets. Physical access to production DSRE TLS CA systems is
restricted to authorized personnel using dual controlled, two-factor
authentication access control mechanisms; is logged; and is monitored and video
recorded on a 24x7 basis.
DSRE PKI
has implemented a backup facility in an alternate location to address the
recovery of the DSRE PKI service and systems in the case of a disaster
scenario.
DSRE TLS
CA systems are protected by dual controlled, two-factor authentication systems,
including biometrics. Access is restricted to a limited number of authorized individuals
with an approved business need to access DSRE systems and cryptographic
materials.
Furthermore,
access to these facilities is reviewed on a periodic basis to determine
compliance.
Cryptographic
hardware and activation materials are protected through the
use of locked racks and safes. Access to cryptographic systems,
hardware, and activation materials is restricted in accordance with §5.2.2.
Participation of a minimum of two (2) trusted individuals is required to obtain
access to the quorum of activation materials needed to activate CA keys.
DSRE TLS
CA facilities are equipped with primary and backup power systems, including
uninterruptible power supply (UPS) systems and backup generators. Also, these
secure facilities are equipped with climate control systems, as appropriate, to
maintain optimal levels of temperature and humidity.
DSRE maintains
controls to minimize the risk of water exposure and damage for CA systems and
cryptographic materials.
CA facilities are equipped with smoke detection
and fire suppression systems.
Media containing production software and system audit information
is stored within secure hosting facilities with appropriate physical and
logical access controls in accordance with DSRE Microsoft Highly Confidential policies.
Media containing copies of production data, i.e., backup of key
files etc., is stored within secure hosting facilities that also adhere to
appropriate physical and logical access controls in accordance with DSRE Microsoft
Highly Confidential policies.
Sensitive waste material is disposed of in a secure fashion.
Sensitive documents and materials are shredded before disposal. Media used to
collect or transmit sensitive information are rendered unreadable before
disposal. Other waste is disposed of in accordance with Microsoft’s normal
waste disposal requirements.
Cryptographic
devices, smart cards, and other devices that may contain private keys or key
material will be physically destroyed or zeroized, if deemed necessary, in
accordance with the manufacturers’ guidance prior to disposal. Authorization is
required for the disposal of all storage devices that contain key materials.
Destruction of CA private keys shall be approved by the PMA and shall be
witnessed by at least 2 individuals in trusted roles, and records of all
disposals shall be maintained by DSRE PKI.
Backups
of the CAs, including backups of system configurations and databases required
to reconstitute PKI systems in the event of failure, are made and transported,
on a periodic basis, to a secured backup location.
Personnel
responsible for CA key management, Certificate issuance, and management of CA
system functions are considered to serve in “trusted roles.”
Within DSRE PKI, the following roles are
implemented:
Trusted Roles
· DSRE PKI Core Team - fulfills and supports PKI
systems and services including designing, building and testing the TLS PKI
system, and cryptographic key management operations, providing support to
customers (i.e., internal business groups), administration of service requests,
and providing support for DSRE TLS RA application and underlying
infrastructure.
Authorized Roles
· DSRE ACE - provides information security related support for the DSRE TLS
CA hierarchy, including performing risk and threat assessments, periodic
vulnerability assessments, and log review and monitoring.
· Policy Management Authority (PMA) - provides guidance for PKI policies.
· DSRE PKI Development Team - provides development, and testing support for
the TLS RA application.
· Microsoft Domains Team - provides support for the DSRE TLS RA
operations by reviewing certificates requests that are flagged for exception
due to domain ownership.
· Site Services/Global Capacity Services - provides facilities assistance including
installation of new hardware and hardware monitoring and support.
· Physical Security - responsible for the physical security of the
data center and storage of the cryptographic materials in safes.
· Infrastructure and Networking - responsible for managing and maintaining
the infrastructure and network components of the DSRE TLS hierarchy.
Cryptographically
sensitive operations within the DSRE PKI such as access to cryptographic
materials and systems, CA key generation, CA key recovery, CA key activation
and CA system configuration requires the participation of multiple trusted
individuals in accordance with §6.2.2. Other operations may require only one
trusted or authorized individual.
See
section §5.3.2.
Roles
requiring separation of duties include, but may not be limited to, the
following:
· Handling of CA key life-cycle management
activities, Certificate life-cycle management activities, CA system
installation, administration, and maintenance activities
· Independent witness during the key ceremony
· RA application developers
· RA application operational support
The DSRE
PKI operation relies on Microsoft Corporate HR policies for personnel
management to ensure the trustworthiness of its staff.
The recruitment and selection practices for Microsoft personnel
shall take into account the background,
qualifications, and experience requirements of each position, which are
compared against the profiles of potential candidates.
DSRE PKI
trusted personnel undergo background checks prior to their commencement of
employment at Microsoft. Such checks include:
· Social Security Number trace;
· County, State, and Federal criminal records
search (7 year search, where permitted by resident
jurisdiction);
· Employment verification (last 7 years or last
three employers); and
· Education verification (highest degree
obtained).
DSRE PKI
employees are required to sign a nondisclosure agreement and are required to
adhere to Microsoft corporate policies and procedures.
DSRE PKI
personnel in trusted roles receive training as needed to perform assigned job
responsibilities relating to CA or RA operations:
· Basic PKI concepts
· Roles and responsibilities
· The policies and practices noted in the CP/CPS
· DSRE PKI security and operational policies and
procedures
Training
curriculum and renewal requirements are determined by DSRE PKI management.
DSRE PKI
provides refresher training as needed to ensure a consistently high level of
awareness and proficiency.
No stipulation.
Unauthorized actions or other violations of DSRE PKI policies and
procedures, and practices as described in this CP/CPS will result in
disciplinary action. Disciplinary actions are taken in accordance with
Microsoft corporate policies.
DSRE PKI
may employ contractors as necessary. Contractors are
required to follow a similar background check process as full-time employees.
DSRE PKI
personnel are required to read this CP/CPS. They are also provided with DSRE PKI
policies, procedures, and other documentation relevant to their job functions.
At a minimum, DSRE PKI logs the following events:
· Significant TLS CA key
life-cycle management events including CA key generation, CA key backup, and
other cryptographic device life-cycle management information
· CA and Subscriber
Certificate life-cycle management events
· Logical
security-related events
· Physical
security-related events
Audit logs are either manually or automatically recorded by the
system and include event identifying parameters i.e., time, date, and personnel
involved in the action.
Audit
logs are reviewed on an as-needed basis and significant events may be
documented in a review summary. Exception based entries corresponding to alerts
or irregularities are highlighted and actions, if any, to resolve noted issues
are also documented.
Logs
are retained as auditable proof of DSRE PKI’s practices as follows:
|
Log
Type |
Minimum Retention Period |
|
Logs
of CA key management activity |
7
years |
|
CA
system logs of Certificate management activity |
7
years |
|
Operating
system logs |
7 years |
|
Physical
access system logs |
7
years |
|
Manual
logs of physical access |
7
years |
|
Video
recording of CA facility access |
90
days |
Production and archived logical and physical audit logs are
protected using a combination of physical and logical access controls.
Audit
logs are backed up on a periodic basis.
Automated
audit data is generated and recorded at the application, database, network and operating system level. Manually generated audit
data is recorded.
Where an event is logged by the audit collection system, no notice
is required to be given to the individual or system that caused the event.
DSRE PKI
maintains detection and prevention controls to protect Certificate Systems
against viruses and malicious software and document and follows a vulnerability
correction process that addresses the identification, review, response, and
remediation of vulnerabilities.
DSRE TLS
CA systems will undergo periodic vulnerability scans and penetration testing as
determined by DSRE PKI.
DSRE PKI maintains an archive of logs that include the recorded
events specified in §5.4.1.
No
stipulation.
Certificates,
CRLs, and other database entries shall contain time and date information.
No stipulation.
Only
authorized designated individuals from DSRE PKI are able to
obtain access to archived records.
CAs
managed and operated by DSRE PKI will stop issuing TLS Certificates and will be
re-keyed or terminated before the maximum key usage period for Certificate
signing is reached in accordance with §6.3.2. The TLS CAs will continue to sign
and publish CRLs until the end of the CA Certificate lifetime. The key
changeover or CA termination process will be performed such that it causes
minimal disruption to Subscribers and Relying Parties. Affected entities will
be notified prior to the planned key changeover.
When DSRE PKI fails to comply with the Mozilla Trusted Root Policy - whether it be a misissuance, a procedural or operational issue, or any other variety of non-compliance - the event is classified as an incident. At a minimum, DSRE PKI will promptly report all incidents to through Mozilla's Bugzilla bug reporting tool, and will regularly update the Incident Report until the corresponding bug is resolved by a Mozilla representative. Issuance of impacted certificates will be ceased until the problem has been prevented from reoccurring.
Changes that are motivated by a security concern
such as certificate misissuance or a root or
intermediate compromise will be treated as a security-sensitive, and a secure
bug will be filed in Bugzilla.
See §5.7.4.
If DSRE PKI discovers, or has reason to believe,
that there has been a compromise of a DSRE TLS CA private key, DSRE PMA will
immediately convene an emergency incident response team to assess the situation
to determine the degree and scope of the incident and take appropriate action
as specified in Microsoft’s corporate information security incident response
plan.
DSRE PKI has established and maintains the following business
continuity capabilities and practices to address recovery of the DSRE PKI
service and systems in the event of a disaster:
· Secure storage of backup cryptographic hardware
modules containing copies of the private keys for TLS CAs managed and operated
by DSRE PKI at a Microsoft facility away from the primary location;
· Secure storage of the requisite activation
materials at a secured facility away from the primary location;
· Secure storage of daily backups of system, data,
and configuration information;
· Secured disaster recovery site at a Microsoft facility
away from the primary location where operations can be restored in the event of
a disaster at the primary location;
· A business continuity strategy that defines the
acceptable Recovery Time Objective (RTO) and Recovery Point Objective (RPO). The
RTO is a maximum three days except for the certificate revocation and CRL
publishing which shall have an RTO of twenty-four hours. The RPO is at maximum
twenty-four hours;
· Disaster recovery plan; and
· Disaster recovery testing performed on at least
an annual basis.
In
the event that it is necessary to terminate the operation of a DSRE TLS CA,
management will plan and coordinate the termination process with its
Subscribers and Relying Parties such that the impact of the termination is
minimized. DSRE PKI will provide as much
prior notice as is reasonable to Subscribers and Relying Parties and preserve
relevant records for a period of time deemed fit for
functional and legal purposes. Relevant Certificates will be revoked no later
than the time of the termination.
DSRE
PKI generates CA key pairs for the DSRE TLS CAs
following a defined key generation process, which is witnessed and performed in
the presence of multiple trusted roles.
CA
key pair generation is performed in accordance with the “DSRE PKI Key
Generation Ceremony Process” and “DSRE PKI Operations Guide” during formal,
pre-scripted ceremonies using hardware cryptographic modules that meet the
requirements of §6.2.1. The CA Key Generation Script (“script”) defines the
specific steps performed during the installation and key generation ceremony
and serves as an audit record. The script includes a list of the specific CA
hardware and cryptographic materials required to be accessed during the
ceremony.
Key
ceremonies require the participation of multiple trusted employees, functioning
in the capacity of pre-allocated ceremony roles, and are performed in
controlled secure facilities. These facilities are secured with multiple tiers
of physical security and are used to store production and backup copies of CA
systems and key materials required for the key generation activities. Physical
access is restricted using dual-controlled, two factor authentication access
control systems, including biometrics. Access to and within the facilities is
monitored via closed circuit televisions (CCTV) and recorded.
Activation
materials are retrieved by assigned shareholders prior to the key ceremony. A
log is maintained of all items removed and replaced from their storage location
citing the individuals’ names, date, time, and purpose of retrieval. Major
ceremony activities are witnessed by an independent observer who attests to the
integrity of the ceremony and records exceptions to the pre-scripted processes.
DSRE PKI
does not generate Subscriber keys. Subscriber key pairs are generated by the end-entity
DSRE PKI Subscriber.
Not applicable.
Issuing CA Certificate requests are generated by
the DSRE PKI team using a controlled process that requires the participation of
multiple trusted individuals. CA Certificate requests are PKCS #10 requests
(signing request) and accordingly contain the requesting CA’s public key and
are digitally signed by the requesting CA’s private key. The PKCS #10 requests
are sent to third party provider to be digitally signed by the third-party Root
CA.
For Subscriber Certificate requests, the Subscriber’s
public key is submitted to the CA using a Certificate request signed with the
Subscriber’s private key. This mechanism ensures that:
· The public key has not been modified during
transit and
· The sender possesses the private key corresponding
to the transferred public key
When DSRE PKI updates signature key pairs it
shall distribute the new public key in a secure fashion. The new public key may
be distributed in a new CA Certificate obtained from the issuer(s) of the
current CA Certificate(s). DSRE TLS CA Certificates will be published in one or
both of the following locations:
· Within the RA database and/or
· Published within the DSRE PKI repository (See
§2.1).
Issuing
CAs under this CP/CPS that sign end-entity Certificate requests and CRLs shall
be generated as defined below:
· Microsoft IT TLS CA 1 shall be generated
with 4096-bit RSA Public Key Modulus
· Microsoft IT TLS CA 2 shall be generated
with 4096-bit RSA Public Key Modulus
· Microsoft IT TLS CA 4 shall be generated
with 4096-bit RSA Public Key Modulus
· Microsoft IT TLS CA 5 shall be generated
with 4096-bit RSA Public Key Modulus
· Microsoft RSA TLS CA 01 shall be generated
with 4096-bit RSA Public Key Modulus
· Microsoft RSA TLS CA 02 shall be generated
with 4096-bit RSA Public Key Modulus
End-entity
Certificates shall use RSA keys whose modulus size in bits is divisible by 8, and is at least 2048.
Not
applicable.
Key
pairs may be used as follows:
|
Entity |
Permitted Key Usage |
|
Issuing
CA |
Signing
of Subscriber Certificates, CRL Signing, and OCSP Responder Certificates
Signing |
|
Subscriber |
Server
Authentication, Client Authentication Exceptions
to the above noted key uses should be approved on a case-by-case basis |
The
key usage extension is set in accordance with the Certificate profile
requirements specified in §7.1.
CA
key pairs are generated in and protected by hardware security modules certified
to FIPS 140 level 3 that meet industry standards for random number and prime
number generation. It is recommended that the Subscriber use a FIPS 140-1
validated cryptographic module for key generation.
The
participation of at least two trusted employees is required to perform
sensitive CA private key operations (e.g., signing operations, CA key backup,
CA key recovery, etc.) for the Issuing CAs. This is enforced through DSRE PKI’s
allocation among persons or groups with trusted roles of the activation
materials, required for CA key activation and through physical access controls
specified in §5.1.2 over the CA systems and related activation materials.
A
threshold (m) number of card sets of the total number (n) of activation
materials, created and distributed for each hardware cryptographic module
security world, is required to initialize a CA private key. At least one
operator card with passphrase shall be required for activating the private key.
Production security worlds created after the approval and publication of this CP/CPS
shall have an “m of n” configuration to support distribution of materials to
individual key shareholders while maintaining redundancy to achieve operational
efficiencies.
|
Assurance
Level |
Required Operator Card Set Threshold |
Required Administrator Card Set
Threshold |
|
High
Assurance |
1
Operator Card |
3
Administrator Cards |
Exceptions
to these policies require the approval of the DSRE PKI Policy Management
Authority. Furthermore, DSRE PKI production security worlds shall not be shared
with non-DSRE PKI groups or used to perform signing activities for test CAs.
CA key pairs, managed and hosted by DSRE PKI group shall
comply with private key multi-person access control requirements defined in
this CP/CPS.
The escrow of CA and Subscriber private keys is not supported by DSRE
PKI.
Backups
of CA private keys are created to facilitate disaster recovery and business
continuity capabilities. Backups of key files are stored in encrypted form and
protected in accordance with media handling practices stated in §5.1.6. DSRE
PKI does not provide private key backup for end-entity Subscriber private keys.
DSRE TLS CA and Subscriber private keys are not
archived.
CA
private keys are generated, stored and backed up in an
encrypted form, and used only within industry-standard hardware cryptographic
modules meeting the requirements of §6.2.1.
See
§6.2.6.
Cryptographic modules used for CA private key protection utilize a
smart card-based activation mechanism (Operator Card) as described in CP/CPS
§6.2.2.
It is
recommended that Subscriber private keys be protected with a pass phrase.
Cryptographic
modules that have been activated shall be secured from unauthorized access.
After use, the cryptographic module shall be deactivated by removal of the
inserted OCS from the card reader. Hardware cryptographic modules are removed
and stored in a secure container when not in use.
CA
private keys shall be destroyed when they are no longer needed, or when the
Certificates to which they correspond expire or are revoked, in the presence of
multiple trusted personnel after approval from the PKI Policy Management
Authority (PMA). When CA key destruction is required, CA private keys shall be destroyed
through zeroization and/or physical destruction of the device in accordance
with manufacturers’ guidelines.
See
§6.2.1.
Copies
of CA and Subscriber TLS Certificates shall be archived in accordance with
§5.5.
For Certificates issued after the effective date
of this CP/CPS, the following key and Certificate usage periods shall be
deployed.
|
Entity
Type |
Maximum Key Usage Period For Certificate signing |
Maximum Key Usage Period For CRL signing |
Maximum Certificate Validity Period |
|
Issuing
CAs |
|||
|
Subscribers |
N/A |
N/A |
800
Days |
Exceptions
to the above noted operational and usage periods shall be approved by the PKI
Policy Management Authority.
Hardware
modules used for CA private key protection utilize a secret sharing mechanism
to activate the CA private key under multi-user control as described in §6.2.2.
Key material created during formal key generation ceremonies, used only when
needed, and stored in a secure site when not in use.
See
§6.4.
See
§6.4.
See
§6.4.
DSRE PKI systems use industry
standard CA software, custom developed RA software, commercially available
cryptographic modules, and smart cards. DSRE PKI systems maintaining CA
software and data files are secured from unauthorized access. Authorized access
to production servers is limited to those individuals with a valid business
reason for such access. Multi-factor authentication is enforced for user
accounts capable of directly causing Certificate issuance.
PKI systems comply with Microsoft corporate information security
policies.
No stipulation.
Custom
developed software is developed, tested, and deployed in accordance with
documented Microsoft Systems Development Lifecycle (SDLC) processes. Approvals
by management are required for key stages of development, including
requirements specifications, design review, user acceptance testing, and
deployment.
DSRE PKI follows Microsoft corporate information
security policies for securing and maintaining the DSRE TLS PKI systems.
Periodic risk assessments and threat analysis are performed by the DSRE
Security Assessment (ACE) team to identify threats and vulnerabilities in the DSRE
TLS PKI systems.
Logical access to the DSRE TLS CA systems is restricted to authorized
individuals in trusted roles. DSRE TLS PKI systems are configured by
removing/disabling accounts, applications, services, protocols, and ports that
are not used in the CA’s operations. Anti-virus and malware detection software
is installed on CA systems.
DSRE PKI
segments Certificate systems into zones based on their functional and logical
relationship.
The zones, on which the DSRE TLS CAs reside, are
protected from unauthorized users through a series of network and host-based
firewalls and other monitoring and detection systems. Firewalls are
configured with rules that support the services, protocols, ports, and
communications that DSRE PKI has identified as necessary for its operations.
Certificates,
CRLs, OCSP entries, and other revocation database entries contain time and date
information.
CA
Certificates within the DSRE PKI shall be X.509 Version 3 and shall conform to
the RFC 5280: Internet X.509 Public Key Infrastructure Certificate and CRL
profile, dated May 2008. As applicable to the Certificate type, Certificates
conform to the current version of the CA/Browser Forum Baseline Requirements
for the Issuance and Management of Publicly-Trusted
Certificates.
At a minimum the following basic fields and prescribed field
attributes are utilized within the CA Certificate profile. Less stringent exceptions
to the given basic profile shall be approved on a case-by-case basis by the PKI
Policy Management Authority based on a valid documented business case.
Issuer
CAs shall generate non-sequential Certificate serial numbers greater than zero (0)
containing at least 64 bits of output from a CSPRNG.
TLS SHA-2 Issuing CA 1 Certificate Profile
|
Field |
Description |
|
Version |
V3 |
|
Serial Number |
Positive integer uniquely assigned by Third Party Root |
|
Signature Algorithm |
SHA256RSA |
|
Issuer |
CN = Baltimore CyberTrust Root OU = CyberTrust O = Baltimore C = IE |
|
Valid From |
Date and time of Certificate issuance. Time synchronized to
Master Clock of U.S. Naval Observatory. Encoded in accordance with
RFC 5280. |
|
Valid To |
Date
and time of Certificate expiration. Time synchronized to Master Clock of U.S.
Naval Observatory. Encoded in accordance with RFC 5280. Maximum
Certificate validity period is 8 years from issuance. |
|
Subject |
CN = Microsoft IT TLS CA 1 OU = Microsoft IT O = Microsoft Corporation L = Redmond S = Washington C = US |
|
Public Key |
RSA (4096 bits) |
|
Certificate Policies |
2.5.29.32.0
(anyPolicy) – All Issuance Policies 1.3.6.1.4.1.311.42.1 |
|
CRL Distribution Points |
<http URL of the Root CA’s CRL service> |
|
Authority Information Access |
[1]Authority Info Access Access Method=On-line Certificate
Status Protocol (1.3.6.1.5.5.7.48.1) Alternative Name: URL= <http
URL of the Third Party Root CA’s OCSP Responder, if
available> |
|
Basic Constraints |
Subject Type = CA Path Length Constraint = 0 |
|
Key Usage |
KeyCertSign cRLSign digitalSignature |
|
Extended Key Usage |
id-kp-serverAuth id-kp-clientAuth id-kp-OCSPSigning |
TLS SHA-2 Issuing CA 2 Certificate Profile
|
Field |
Description |
|
Version |
V3 |
|
Serial Number |
Positive integer uniquely assigned by Root |
|
Signature Algorithm |
SHA256RSA |
|
Issuer |
CN = Baltimore CyberTrust Root OU = CyberTrust O = Baltimore C = IE |
|
Valid From |
Date and time of Certificate issuance. Time synchronized to
Master Clock of U.S. Naval Observatory. Encoded in accordance with
RFC 5280. |
|
Valid To |
Date
and time of Certificate expiration. Time synchronized to Master Clock of U.S.
Naval Observatory. Encoded in accordance with RFC 5280. Maximum
Certificate validity period is 8 years from issuance. |
|
Subject |
CN = Microsoft IT TLS CA 2 OU = Microsoft IT O = Microsoft Corporation L = Redmond S = Washington C = US |
|
Public Key |
RSA (4096 bits) |
|
Certificate Policies |
2.5.29.32.0
(anyPolicy) – All Issuance Policies 1.3.6.1.4.1.311.42.1 |
|
CRL Distribution Points |
<http URL of the Root CA’s CRL service> |
|
Authority Information Access |
[1]Authority Info Access Access Method=On-line Certificate
Status Protocol (1.3.6.1.5.5.7.48.1) Alternative Name: URL= <http
URL of the Third Party Root CA’s OCSP Responder, if
available> |
|
Basic Constraints |
Subject Type = CA Path Length Constraint = 0 |
|
Key Usage |
KeyCertSign cRLSign digitalSignature |
|
Extended Key Usage |
id-kp-serverAuth id-kp-clientAuth id-kp-OCSPSigning |
TLS SHA-2 Issuing CA 4 Certificate Profile
|
Field |
Description |
|
Version |
V3 |
|
Serial Number |
Positive integer uniquely assigned by Root |
|
Signature Algorithm |
SHA256RSA |
|
Issuer |
CN = Baltimore CyberTrust Root OU = CyberTrust O = Baltimore C = IE |
|
Valid From |
Date and time of Certificate issuance. Time synchronized to
Master Clock of U.S. Naval Observatory. Encoded in accordance with
RFC 5280. |
|
Valid To |
Date
and time of Certificate expiration. Time synchronized to Master Clock of U.S.
Naval Observatory. Encoded in accordance with RFC 5280. Maximum
Certificate validity period is 8 years from issuance. |
|
Subject |
CN = Microsoft IT TLS CA 4 OU = Microsoft IT O = Microsoft Corporation L = Redmond S = Washington C = US |
|
Public Key |
RSA (4096 bits) |
|
Certificate Policies |
2.5.29.32.0
(anyPolicy) – All Issuance Policies 1.3.6.1.4.1.311.42.1 |
|
CRL Distribution Points |
<http URL of the Root CA’s CRL service> |
|
Authority Information Access |
[1]Authority Info Access Access Method=On-line Certificate
Status Protocol (1.3.6.1.5.5.7.48.1) Alternative Name: URL= <http
URL of the Third Party Root CA’s OCSP Responder, if
available> |
|
Basic Constraints |
Subject Type = CA Path Length Constraint = 0 |
|
Key Usage |
KeyCertSign cRLSign digitalSignature |
|
Extended Key Usage |
id-kp-serverAuth id-kp-clientAuth id-kp-OCSPSigning |
TLS SHA-2 Issuing CA 5 Certificate Profile
|
Field |
Description |
|
Version |
V3 |
|
Serial Number |
Positive integer uniquely assigned by Root |
|
Signature Algorithm |
SHA256RSA |
|
Issuer |
CN = Baltimore CyberTrust Root OU = CyberTrust O = Baltimore C = IE |
|
Valid From |
Date and time of Certificate issuance. Time synchronized to
Master Clock of U.S. Naval Observatory. Encoded in accordance with
RFC 5280. |
|
Valid To |
Date
and time of Certificate expiration. Time synchronized to Master Clock of U.S.
Naval Observatory. Encoded in accordance with RFC 5280. Maximum
Certificate validity period is 8 years from issuance. |
|
Subject |
CN = Microsoft IT TLS CA 5 OU = Microsoft IT O = Microsoft Corporation L = Redmond S = Washington C = US |
|
Public Key |
RSA (4096 bits) |
|
Certificate Policies |
2.5.29.32.0
(anyPolicy) – All Issuance Policies 1.3.6.1.4.1.311.42.1 |
|
CRL Distribution Points |
<http URL of the Root CA’s CRL service> |
|
Authority Information Access |
[1]Authority Info Access Access Method=On-line Certificate
Status Protocol (1.3.6.1.5.5.7.48.1) Alternative Name: URL= <http
URL of the Third Party Root CA’s OCSP Responder, if
available> |
|
Basic Constraints |
Subject Type = CA Path Length Constraint = 0 |
|
Key Usage |
KeyCertSign cRLSign digitalSignature |
|
Extended Key Usage |
id-kp-serverAuth id-kp-clientAuth id-kp-OCSPSigning |
TLS SHA-2 Issuing CA 01 Certificate Profile
|
Field |
Description |
|
Version |
V3 |
|
Serial Number |
Positive integer uniquely assigned by Root |
|
Signature Algorithm |
SHA256RSA |
|
Issuer |
CN = Baltimore CyberTrust
Root OU = CyberTrust O = Baltimore C = IE |
|
Valid From |
Date and time of Certificate issuance. Time
synchronized to Master Clock of U.S. Naval Observatory. Encoded in accordance
with RFC 5280. |
|
Valid To |
Date
and time of Certificate expiration. Time synchronized to Master Clock of U.S.
Naval Observatory. Encoded in accordance with RFC 5280. Maximum
Certificate validity period is 8 years from issuance. |
|
Subject |
CN
= Microsoft RSA TLS CA 01 O =
Microsoft Corporation C =
US |
|
Public Key |
RSA (4096 bits) |
|
Certificate Policies |
2.23.140.1.2.1 2.23.140.1.2.2 1.3.6.1.4.1.311.42.1 |
|
CRL Distribution Points |
<http URL of the Root CA’s CRL service> |
|
Authority Information Access |
[1]Authority Info
Access Access
Method=On-line Certificate Status Protocol (1.3.6.1.5.5.7.48.1) Alternative
Name: URL= <http
URL of the Third Party Root CA’s OCSP Responder, if
available> |
|
Basic Constraints |
Subject Type = CA Path Length Constraint = 0 |
|
Key Usage |
KeyCertSign cRLSign DigitalSignature Off-line CRL Signing |
|
Extended Key Usage |
id-kp-serverAuth id-kp-clientAuth |
TLS SHA-2 Issuing CA 02 Certificate Profile
|
Field |
Description |
|
Version |
V3 |
|
Serial Number |
Positive integer uniquely assigned by Root |
|
Signature Algorithm |
SHA256RSA |
|
Issuer |
CN = Baltimore CyberTrust
Root OU = CyberTrust O = Baltimore C = IE |
|
Valid From |
Date and time of Certificate issuance. Time
synchronized to Master Clock of U.S. Naval Observatory. Encoded in accordance
with RFC 5280. |
|
Valid To |
Date
and time of Certificate expiration. Time synchronized to Master Clock of U.S.
Naval Observatory. Encoded in accordance with RFC 5280. Maximum
Certificate validity period is 8 years from issuance. |
|
Subject |
CN
= Microsoft RSA TLS CA 02 O =
Microsoft Corporation C =
US |
|
Public Key |
RSA (4096 bits) |
|
Certificate Policies |
2.23.140.1.2.1 2.23.140.1.2.2 1.3.6.1.4.1.311.42.1 |
|
CRL Distribution Points |
<http URL of the Root CA’s CRL
service> |
|
Authority Information Access |
[1]Authority Info
Access Access
Method=On-line Certificate Status Protocol (1.3.6.1.5.5.7.48.1) Alternative
Name: URL= <http
URL of the Third Party Root CA’s OCSP Responder, if
available> |
|
Basic Constraints |
Subject Type = CA Path Length Constraint = 0 |
|
Key Usage |
KeyCertSign cRLSign DigitalSignature Off-line CRL Signing |
|
Extended Key Usage |
id-kp-serverAuth id-kp-clientAuth |
SHA-2 End-entity Certificate Profile
End-user
Subscriber Certificates shall be X.509 Version 3.
|
Field |
Description |
|
Version |
V3 |
|
Serial
Number |
Positive
integer uniquely assigned by CA that exhibits at least 8 bytes of entropy |
|
Signature
Algorithm |
SHA256RSA |
|
Issuer |
CN
= <Issuing CA’s common name> OU
= Microsoft IT O =
Microsoft Corporation L =
Redmond S =
Washington C =
US |
|
Valid
From |
Date
and time of Certificate issuance. Time synchronized to Master Clock of U.S.
Naval Observatory. Encoded in accordance with RFC 5280. |
|
Valid
To |
Date and time of Certificate expiration. Time synchronized to Master Clock of U.S. Naval Observatory. Encoded in accordance with RFC 5280. Maximum
Certificate validity period is 800 Days from issuance for Fully Qualified
Domain Names and public IP Address certificates. |
|
Subject |
CN
= <Subscriber Name> OU
= <Subscriber Organization Unit> (Optional) O =
<Subscriber Company Name> (Optional, Required
if OU is present) i.e.,
Microsoft or Microsoft Corporation S =
State OR L = Locality (Optional, Required if O
is present, Prohibited if O is not present) C =
Country Name (Optional, Required if O is present) |
|
Public
Key |
RSA
(2048 bits) |
|
Subject
Alternate Name |
<DNS
Name(s)> |
|
Certificate
Policies |
1.3.6.1.4.1.311.42.1 |
|
CRL
Distribution Points |
[1]CRL Distribution Point Distribution
Point Name: Full
Name: URL= http://mscrl.microsoft.com/pki/mscorp/crl/<Issuing
CA>(n*).crl (or) http://mscrl.microsoft.com/pki/mscorp/crl/msitwww2(n*).crl [1]CRL Distribution Point Distribution
Point Name: Full
Name: URL= http://crl.microsoft.com/pki/mscorp/crl/<Issuing
CA>(n*).crl (or) http://crl.microsoft.com/pki/mscorp/crl/msitwww2(n*).crl More
than one CRL Distribution Points may be specified in the end-entity
certificate. *an
incremental integer value assigned by Windows Active Directory Certificate
Services that represents the version number of the CRL |
|
Authority
Information Access |
[1]Authority Info Access Access
Method=Certification Authority Issuer (1.3.6.1.5.5.7.48.2) Alternative
Name: URL= http://www.microsoft.com/pki/mscorp/msitwww2(n*).crt (or) http://www.microsoft.com/pki/mscorp/<Issuing CA name>.crt
Access
Method=On-line Certificate Status Protocol (1.3.6.1.5.5.7.48.1) Alternative
Name: URL=http://ocsp.msocsp.com |
|
Basic
Constraints |
NOT
POPULATED |
|
Key
Usage |
(Optional) |
|
Extended
Key Usage |
id-kp-serverAuth id-kp-clientAuth |
WTTLSDVLegacy End-entity
Certificate Profile
End-user
Subscriber Certificates shall be X.509 Version 3.
|
Field |
Description |
|
Version |
V3 |
|
Serial
Number |
Positive
integer uniquely assigned by CA that exhibits at least 8 bytes of entropy |
|
Signature
Algorithm |
SHA256RSA |
|
Issuer |
CN = <Issuing CA’s common name> OU
= Microsoft IT O =
Microsoft Corporation L =
Redmond S =
Washington C =
US |
|
Valid
From |
Date
and time of Certificate issuance. Time synchronized to Master Clock of U.S.
Naval Observatory. Encoded in accordance with RFC 5280. |
|
Valid
To |
Date
and time of Certificate expiration. Time synchronized to Master Clock of U.S.
Naval Observatory. Encoded in accordance with RFC 5280. Maximum
Certificate validity period is 372 Days from issuance for Fully Qualified
Domain Names and public IP Address certificates. |
|
Subject |
CN
= <Subscriber Name> C =
Country Code (Optional) |
|
Public
Key |
RSA
(2048 bits) |
|
Subject
Alternate Name |
<DNS
Name(s)> |
|
Certificate
Policies |
Microsoft IT
CPS (1.3.6.1.4.1.311.42.1) Domain
Validated (2.23.140.1.2.1) |
|
CRL
Distribution Points |
[1]CRL Distribution Point Distribution
Point Name: Full
Name: URL= http://mscrl.microsoft.com/pki/mscorp/crl/<Issuing
CA>(n*).crl [1]CRL Distribution Point Distribution
Point Name: Full
Name: URL= http://crl.microsoft.com/pki/mscorp/crl/<Issuing
CA>(n*).crl More
than one CRL Distribution Points may be specified in the end-entity
certificate. *an
incremental integer value assigned by Windows Active Directory Certificate
Services that represents the version number of the CRL |
|
Authority
Information Access |
[1]Authority Info Access Access
Method=Certification Authority Issuer (1.3.6.1.5.5.7.48.2) Alternative
Name: URL= http://www.microsoft.com/pki/mscorp/<Issuing CA
name>.crt
Access
Method=On-line Certificate Status Protocol (1.3.6.1.5.5.7.48.1) Alternative
Name: URL=http://ocsp.msocsp.com |
|
Basic
Constraints |
NOT
POPULATED |
|
Key
Usage |
(Optional) |
|
Extended
Key Usage |
id-kp-serverAuth id-kp-clientAuth |
WTTLSOVLegacy End-entity Certificate Profile
End-user
Subscriber Certificates shall be X.509 Version 3.
|
Field |
Description |
|
Version |
V3 |
|
Serial
Number |
Positive
integer uniquely assigned by CA that exhibits at least 8 bytes of entropy |
|
Signature
Algorithm |
SHA256RSA |
|
Issuer |
CN = <Issuing CA’s common name> OU
= Microsoft IT O =
Microsoft Corporation L =
Redmond S =
Washington C =
US |
|
Valid
From |
Date
and time of Certificate issuance. Time synchronized to Master Clock of U.S.
Naval Observatory. Encoded in accordance with RFC 5280. |
|
Valid
To |
Date
and time of Certificate expiration. Time synchronized to Master Clock of U.S.
Naval Observatory. Encoded in accordance with RFC 5280. Maximum
Certificate validity period is 372 Days from issuance for Fully Qualified
Domain Names |
|
Subject |
CN = <Subscriber Name> OU
= <Subscriber Organization Unit> (Optional) O =
<Subscriber Company Name> i.e.,
Microsoft or Microsoft Corporation S =
State AND/OR L = Locality C =
Country Name |
|
Public
Key |
RSA
(2048 bits) |
|
Subject
Alternate Name |
<DNS
Name(s)> |
|
Certificate
Policies |
Microsoft IT
CPS (1.3.6.1.4.1.311.42.1) Organization
Validated (2.23.140.1.2.2) |
|
CRL
Distribution Points |
[1]CRL Distribution Point Distribution
Point Name: Full
Name: URL= http://mscrl.microsoft.com/pki/mscorp/crl/<Issuing
CA>(n*).crl [1]CRL Distribution Point Distribution
Point Name: Full
Name: URL= http://crl.microsoft.com/pki/mscorp/crl/<Issuing
CA>(n*).crl More
than one CRL Distribution Points may be specified in the end-entity
certificate. *an
incremental integer value assigned by Windows Active Directory Certificate
Services that represents the version number of the CRL |
|
Authority
Information Access |
[1]Authority Info Access Access
Method=Certification Authority Issuer (1.3.6.1.5.5.7.48.2) Alternative
Name: URL= http://www.microsoft.com/pki/mscorp/<Issuing CA
name>.crt
Access
Method=On-line Certificate Status Protocol (1.3.6.1.5.5.7.48.1) Alternative
Name: URL=http://ocsp.msocsp.com |
|
Basic
Constraints |
NOT
POPULATED |
|
Key
Usage |
digital
signature key
encipherment data
encipherment |
|
Extended
Key Usage |
id-kp-serverAuth id-kp-clientAuth |
WTTLSDV End-entity Certificate Profile
End-user
Subscriber Certificates shall be X.509 Version 3.
|
Field |
Description |
|
Version |
V3 |
|
Serial
Number |
Positive
integer uniquely assigned by CA that exhibits at least 8 bytes of entropy |
|
Signature
Algorithm |
SHA256RSA |
|
Issuer |
CN
= <Issuing CA’s common name> O =
Microsoft Corporation C =
US |
|
Valid
From |
Date
and time of Certificate issuance. Time synchronized to Master Clock of U.S.
Naval Observatory. Encoded in accordance with RFC 5280. |
|
Valid
To |
Date
and time of Certificate expiration. Time synchronized to Master Clock of U.S.
Naval Observatory. Encoded in accordance with RFC 5280. Maximum
Certificate validity period is 372 Days from issuance for Fully Qualified
Domain Names and public IP Address certificates. |
|
Subject |
CN = <Subscriber Name> C =
Country Code (Optional) |
|
Public
Key |
RSA
(2048 bits) |
|
Subject
Alternate Name |
<DNS
Name(s)> |
|
Certificate
Policies |
Microsoft IT
CPS (1.3.6.1.4.1.311.42.1) Domain
Validated (2.23.140.1.2.1) |
|
CRL
Distribution Points |
[1]CRL Distribution Point Distribution
Point Name: Full
Name: URL= http://mscrl.microsoft.com/pki/mscorp/crl/<Issuing
CA>(n*).crl [1]CRL Distribution Point Distribution
Point Name: Full
Name: URL= http://crl.microsoft.com/pki/mscorp/crl/<Issuing
CA>(n*).crl More
than one CRL Distribution Points may be specified in the end-entity
certificate. *an
incremental integer value assigned by Windows Active Directory Certificate
Services that represents the version number of the CRL |
|
Authority
Information Access |
[1]Authority Info Access Access
Method=Certification Authority Issuer (1.3.6.1.5.5.7.48.2) Alternative
Name: URL= http://www.microsoft.com/pki/mscorp/<Issuing CA
name>.crt
Access
Method=On-line Certificate Status Protocol (1.3.6.1.5.5.7.48.1) Alternative
Name: URL=http://ocsp.msocsp.com |
|
Basic
Constraints |
NOT
POPULATED |
|
Key
Usage |
(Optional) |
|
Extended
Key Usage |
id-kp-serverAuth id-kp-clientAuth |
WTTLSOV End-entity Certificate Profile
End-user
Subscriber Certificates shall be X.509 Version 3.
|
Field |
Description |
|
Version |
V3 |
|
Serial
Number |
Positive
integer uniquely assigned by CA that exhibits at least 8 bytes of entropy |
|
Signature
Algorithm |
SHA256RSA |
|
Issuer |
CN
= <Issuing CA’s common name> O =
Microsoft Corporation C =
US |
|
Valid
From |
Date
and time of Certificate issuance. Time synchronized to Master Clock of U.S.
Naval Observatory. Encoded in accordance with RFC 5280. |
|
Valid
To |
Date
and time of Certificate expiration. Time synchronized to Master Clock of U.S.
Naval Observatory. Encoded in accordance with RFC 5280. Maximum
Certificate validity period is 372 Days from issuance for Fully Qualified
Domain Names |
|
Subject |
CN = <Subscriber Name> OU
= <Subscriber Organization Unit> (Optional) O =
<Subscriber Company Name> i.e.,
Microsoft or Microsoft Corporation S =
State AND/OR L = Locality C =
Country Name |
|
Public
Key |
RSA
(2048 bits) |
|
Subject
Alternate Name |
<DNS
Name(s)> |
|
Certificate
Policies |
Microsoft IT
CPS (1.3.6.1.4.1.311.42.1) Organization
Validated (2.23.140.1.2.2) |
|
CRL
Distribution Points |
[1]CRL Distribution Point Distribution
Point Name: Full
Name: URL= http://mscrl.microsoft.com/pki/mscorp/crl/<Issuing
CA>(n*).crl [1]CRL Distribution Point Distribution
Point Name: Full
Name: URL= http://crl.microsoft.com/pki/mscorp/crl/<Issuing
CA>(n*).crl More
than one CRL Distribution Points may be specified in the end-entity
certificate. *an
incremental integer value assigned by Windows Active Directory Certificate
Services that represents the version number of the CRL |
|
Authority
Information Access |
[1]Authority Info Access Access
Method=Certification Authority Issuer (1.3.6.1.5.5.7.48.2) Alternative
Name: URL= http://www.microsoft.com/pki/mscorp/<Issuing CA
name>.crt
Access
Method=On-line Certificate Status Protocol (1.3.6.1.5.5.7.48.1) Alternative
Name: URL=http://ocsp.msocsp.com |
|
Basic
Constraints |
NOT
POPULATED |
|
Key
Usage |
(Optional) |
|
Extended
Key Usage |
id-kp-serverAuth id-kp-clientAuth |
DSRE PKI
hierarchy Certificates are X.509 version 3 Certificates.
The
extensions defined for DSRE IT PKI X.509 v3 Certificates provide methods for
associating additional attributes with users or public keys and for managing
the certification hierarchy. Each extension in a Certificate is designated as
either critical or non-critical.
Certificate
extensions and their criticality, as well as cryptographic algorithm object
identifiers, are populated according to the IETF RFC 5280 standards and
recommendations and CA / Browser Forum Baseline Requirements. The name forms
for Subscribers are enforced through DSRE PKI internal policies and the
authentication policies described elsewhere in this CP/CPS.
The
key usage extension defines the purpose (e.g., encipherment, signature,
Certificate signing) of the key contained in the Certificate. This extension
SHALL appear in Certificates that contain public keys that are used to validate
digital signatures on other public key Certificates or CRLs. When this
extension appears, it may be marked critical.
The
Certificate Policies extension of DSRE PKI X.509 Version 3 Certificates
includes a policy identifier, that indicates a Certificate Policy asserting DSRE
TLS CA's adherence to and compliance with CA/Browser Forum’s TLS Baseline
Requirements.
The subjectAltName extension of DSRE PKI X.509 Version 3
Certificates is utilized. This extension shall contain at least one entry. Each
entry shall be either a dNSName containing the Fully-Qualified Domain Name or an IPAddress
containing the IP address of a server.
BasicConstraints extension shall not be present in DSRE TLS CA end-user Subscriber
Certificates.
DSRE PKI shall make use of the ExtendedKeyUsage extension for certain types of X.509
Version 3 Certificates. This extension indicates one or more purposes for which
the certified public key may be used, in addition to or in place of the basic
purposes indicated in the key usage extension.
DSRE PKI
X.509 Version 3 end user subscriber certificates include the CRLDistributionPoints extension containing the URL of the
location where a Relying Party can obtain a CRL to check the certificate’s
status. The criticality field of this extension is set to FALSE.
Most DSRE
PKI X.509 Version 3 end user subscriber certificates include the authority key
identifier extension to provide a means of identifying the public key
corresponding to the private key used to sign the respective Certificate. When
used, the criticality field of this extension is set to FALSE.
Most DSRE
PKI X.509 Version 3 end user Subscriber Certificates include the subject key
identifier extension to provide a means of identifying the occurrence of a particular
public key. When used, the criticality field of this extension is set to FALSE.
A Pre-certificate,
as described in RFC 6962 – Certificate Transparency, shall not be considered to
be a “certificate” subject to the requirements of RFC 5280 ‐ Internet X.509 Public Key Infrastructure
Certificate and Certificate Revocation List (CRL) Profile under the CA/Browser
Forum's Baseline Requirements for the Issuance and Management of
Publicly-Trusted Certificates.
Certificates issued under this CP/CPS shall use
signature algorithms indicated by the following OIDs:
|
Signature Algorithm |
OID ASN.1 |
Status |
|
sha256WithRSAEncryption |
{iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs-1(1) |
Acceptable |
|
sha384WithRSAEncryption |
{iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs-1(1) sha384WithRSAEncryption(12)} |
Acceptable |
|
sha512WithRSAEncryption |
{iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs-1(1) sha512WithRSAEncryption(13)} |
Acceptable |
Certificates created with deprecated signature
algorithms adhere to all the requirements of this CP/CPS with the exception
that the Certificate is generated with deprecated signature algorithm.
Certificates issued under this CP/CPS shall use
the following OIDs to identify the algorithm associated with the subject key:
|
rsaEncryption |
{iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs-1(1) 1} |
Issuing
CA and Subscriber Certificates are populated in accordance with Certificate
profiles listed in § 7.1.
No
additional stipulation other than § 7.1.
The DSRE
PKI CP/CPS will use a Policy Identifier of 1.3.6.1.4.1.311.42.1 in
all Certificates it issues from the effective date of this version of the
CP/CPS.
The DSRE
PKI CP/CPS will be hot linked from the Certificate Policies in all Certificates
it issues from the publication of this version of the CP/CPS.
No stipulation.
No stipulation.
The
following CRL profile is used by Issuing CAs within the DSRE TLS CA hierarchy.
|
Field |
Description |
|
Version |
V2 |
|
Signature |
SHA2 |
|
Issuer |
Subject
of Issuer |
|
This
Update (Effective Date) |
Date
and time of CRL issuance. |
|
Next
Update |
10
days (not to exceed) |
|
Revoked
Certificates |
List
of information regarding revoked Certificates. CRL entries include: · Serial Number,
identifying the revoked Certificate · Revocation Date,
including the date and time of Certificate revocation |
|
CRL
Entry Extensions |
Not
used. |
See
§7.2.
The
profile for OCSP responses issued by the DSRE PKI conforms to the standards as
described in [RFC2560].
DSRE Issuing
CAs shall issue Version 1 OCSP responses.
No
stipulation.
CAs
within the DSRE TLS CA hierarchy are subject to an annual examination to assess
compliance with the DSRE PKI TLS policies and procedures (including the DSRE PKI
TLS CP/CPS), the American Institute of Certified Public Accountants (AICPA)
& Canadian Institute of Chartered Accountants (CICA) WebTrust
for Certification Authorities (WebTrust for CAs)
examination criteria, and the WebTrust for CAs TLS
Baseline Requirements examination criteria.
Auditors demonstrating proficiency in public key infrastructure
technology, information security tools and techniques, security auditing, and
the third-party attestation function shall perform the annual examination.
The
entity that performs the annual examination is organizationally independent of DSRE
PKI.
The scope of the annual “period-of-time” examination shall include
the requirements of the DSRE PKI CP/CPS, CA environmental controls, CA key
management, and Certificate life-cycle management.
The CAs are audited in accordance with Mozilla's Root Store
Policy. If the CA has a currently valid audit report at the time of creation of
the certificate, then the new certificate will appear on the CA's next periodic
audit reports.
Newly added Intermediate CA certificates will be publicly
disclosed in the CCADB within a week of Intermediate CA certificate creation,
and before any such subordinate CA is allowed to issue
certificates. All disclosure will be made freely available and without
additional requirements, including, but not limited to, registration, legal
agreements, or restrictions on redistribution of the certificates in whole or
in part.
All CA certificates that are capable of being used to issue new
certificates, and which directly or transitively chain to a certificate
included in Mozilla's CA Certificate Program, will be operated in accordance
with Mozilla Trusted Root Program policy and will either be technically
constrained or be publicly disclosed and audited.
Significant
deficiencies identified during the compliance examination will result in a determination
of actions to be taken. DSRE PKI makes this determination with input from the
auditor. Management is responsible for ensuring that corrective action plans
are promptly developed, and corrective action is taken within a period of time commensurate with the significance of such
matters identified.
Compliance examination results are communicated to DSRE PKI
management and others deemed appropriate by management.
DSRE PKI
currently does not charge Certificate issuance or Certificate revocation fees
and reserves the right to charge fees for these or other DSRE PKI provided
services in the future.
DSRE PKI reserves the right to charge a fee for making a
Certificate available in a repository or otherwise.
DSRE PKI does not charge a fee as a condition of making the CRLs
and OCSP status checking available as required by §4.9 and §4.10 available in a
repository or otherwise available to Relying Parties. DSRE PKI reserves the
right to charge a fee for providing customized CRLs or other value-added
revocation and status information services.
DSRE PKI does not charge a fee for accessing this CP/CPS. However,
any use of the CP/CPS for purposes other than viewing the document, including
reproduction, redistribution, modification, or creation of derivative works,
may be subject to a license agreement with the entity holding the copyright to
the document.
Not
Applicable.
Not
Applicable.
DSRE PKI
customers that maintain assets outside the realm of the DSRE PKI environment
shall have access to sufficient financial resources to support operations and
perform duties in accordance with the DSRE PKI CP/CPS.
Not
Applicable.
Sensitive DSRE PKI information shall remain confidential to DSRE PKI.
The following information is considered confidential to DSRE PKI and may not be
disclosed:
· DSRE PKI policies, procedures and technical
documentation supporting this CP/CPS;
· Subscriber registration records, including:
Certificate applications, whether approved or rejected, proof of identification
documentation and details;
· Certificate information collected as part of the
registration records, beyond that which is required to be included in
Subscriber Certificates;
· Audit trail records;
· Any private key within the DSRE TLS CA
hierarchy; and
· Compliance audit results except for WebTrust for CAs audit reports which may be published at
the discretion of DSRE PKI Management.
This
CP/CPS and the Certificates and CRLs issued by DSRE PKI are not considered
confidential.
DSRE PKI
participants receiving private information shall secure it from compromise and
disclosure to third parties.
See
§9.3.1.
DSRE PKI
shall follow the governing principles established by the Microsoft privacy
statement located at https://privacy.microsoft.com/en-us/ with regards to the collection, handling,
and storage of private information during the provision of DSRE TLS CA
services.
Any
information about Subscribers that is not publicly available through the
content of the issued Certificate and CRLs is treated as private.
Subject
to local laws, all information made public in a Certificate is deemed not
private.
DSRE PKI
participants receiving private information shall secure it from compromise and
disclosure to third parties and shall comply with all local privacy laws in
their jurisdiction.
Unless
where otherwise stated in this CP/CPS, the applicable Privacy Policy or by
agreement, private information will not be used without the consent of the
party to whom that information applies. This section is subject to applicable
privacy laws.
DSRE PKI
shall be entitled to disclose Confidential/Private Information if, in good
faith, DSRE PKI believes that:
· Disclosure is necessary in response to subpoenas
and search warrants
· Disclosure is necessary in response to judicial,
administrative, or other legal process during the discovery process in a civil
or administrative action, such as subpoenas, interrogatories, requests for
admission, and requests for production of documents.
The
following are the property of Microsoft:
· This CP/CPS;
· Policies and procedures supporting the operation
of DSRE PKI;
· Certificates and CRLs issued by DSRE PKI managed
CAs;
· Distinguished Names (DNs) used to represent
entities within the DSRE TLS CA hierarchy; and
· CA infrastructure and Subscriber key pairs.
DSRE PKI
participants acknowledge that DSRE PKI retains all Intellectual Property Rights
in and to this CP/CPS.
DSRE PKI
warrants and promises to provide certification authority services substantially
in compliance with this CP/CPS and the relevant Microsoft Certificate Policies.
DSRE PKI makes no other warranties or promises and has no further obligations
to Subscribers or Relying Parties, except as set forth under this CP/CPS.
See §9.6
See §9.6
See §9.6
See §9.6
See §9.6
Except
for express warranties stated in this CP/CPS, DSRE PKI disclaims all other
warranties, promises and other obligations. In addition, DSRE PKI is not liable
for any loss:
· To CA or RA services due to war, natural
disasters or other uncontrollable forces;
· Incurred between the time a Certificate is
revoked and the next scheduled issuance of a CRL;
· Due to unauthorized use of Certificates issued
by DSRE PKI, or use of Certificates beyond the prescribed use defined by this
CP/CPS;
· Arising from the negligent or fraudulent use of
Certificates or CRLs issued by the DSRE PKI; and
· Due to disclosure of personal information
contained within Certificates, CRLs or OCSP responses.
In no
event shall DSRE PKI be liable for any indirect, consequential, incidental,
special or punitive damages, or for any loss of profits, loss of data, or other
indirect or consequential damages arising from or in connection with the use,
delivery, license, availability or non-availability, performance or
nonperformance of Certificates, digital signatures, the repository, or any
other transactions or services offered or contemplated by this CP/CPS, even if DSRE
PKI has been advised of the possibility of such damages.
By their applying for and being issued
Certificates, or otherwise relying upon such Certificates, Subscribers, and
Relying Parties, agree to indemnify, defend, and hold harmless the CA, and its
personnel, organizations, entities, subcontractors, suppliers, vendors,
representatives, and agents from any errors, omissions, acts, failures to act,
or negligence resulting in liability, losses, damages, suits, or expenses of
any kind, due to or otherwise proximately caused by the use or publication of a
Certificate that arises from the Subscriber’s failure to provide the CA with
current, accurate, and complete information at the time of Certificate
application or the Subscriber’s errors, omissions, acts, failures to act, and
negligence.
The CA and its RAs are not the agents,
fiduciaries, trustees, or other representatives of Subscribers or Relying
Parties.
The
CP/CPS becomes effective upon publication in the DSRE PKI documentation
repository.
This
CP/CPS, as amended from time to time, shall remain in force until it is
replaced by a new version. Amendments to this CP/CPS become effective upon
publication in the DSRE PKI documentation repository.
No stipulation.
No stipulation.
Severance or merger may result in changes to the
scope, management, and/or operations of this CA. In such an event, this
CP/CPS may require modification as well. Changes to the operations will occur
consistent with the CA’s disclosed CP/CPS management processes.
Notification will be provided to Mozilla,
Microsoft, and Apple via CCADB.
Amendments
to this CP/CPS may be made by the DSRE PKI and shall be approved by the DSRE PKI
Policy Management Authority as per §1.5.4
No stipulation.
No
stipulation.
In
the event of any dispute involving the services or provisions covered by this
CP/CPS, the aggrieved party shall notify a member of DSRE PKI management
regarding the dispute. DSRE PKI management will involve the appropriate
Microsoft personnel to resolve the dispute.
This
CP/CPS is governed by the laws in force in the State of Washington and the
United States of America.
See
§9.14.
This
CP/CPS shall be binding on all successors of the parties.
If
any provision of this CP/CPS is found to be unenforceable, the remaining
provisions shall be interpreted to best carry out the reasonable intent of the
parties. It is expressly agreed that every provision of this CP/CPS that
provides for a limitation of liability or exclusion of damages, disclaimer or
limitation of any warranties, promises or other obligations, is intended to be
severable and independent of any other provision and is to be enforced as such.
This
CP/CPS shall be interpreted consistently with what is commercially reasonable
in good faith under the circumstances and considering its international scope
and uniform application. Failure by any person to enforce a provision of this
CP/CPS will not be deemed a waiver of future enforcement of that or any other
provision.
Any
notice, demand, or request pertaining to this CP/CPS shall be communicated
either using digitally signed messages consistent with this CP/CPS, or in
writing. Electronic communications shall be effective when received by the
intended recipient.
See §9.16
See §9.16
See §9.16
See §9.16
See §9.16
See §9.16